As we rely more and more on computers and computer networks, computing security becomes increasingly more important. We read in the newspaper about cyber criminals breaking into computers and computer networks and stealing critical information such as credit card and bank account information. We are always on the lookout for computer viruses that may attack and destroy information on our computers. Imagine the harm that could result if confidential computerized medical or personnel records are broken into and distributed over the Internet.
Much has been done to solve these problems. For example, tools have been developed that allow computers to communicate securely. In the context of the World Wide Web, a security protocol known as Secure Sockets Layer (SSL) provides both privacy (e.g., secrecy) and authentication (e.g., confidence that a computer's and/or user's asserted identity is true). The SSL technology has been built into most Internet browsers and web servers, and so has become widely available to protect electronic commerce and other sensitive communications.
The SSL protocol works by encrypting data passing between computers through use of encryption keys and associated encryption techniques. The SSL technology also provides secure authentication over a series of successive data exchanges. This authentication for example prevents an attacker from injecting his or her own computing device between already-communicating computers to intercept sensitive information and/or insert inauthentic information (e.g., substituting the attacker's own shipping address for that of a legitimate user) into the data stream being exchanged. See also a related Transport Layer Security (TLS) protocol that has become an Internet standard (RFC 2246). Other protocols such as for example SSH (Secure Shell) also exist.
FIG. 1 shows an example use of such security protocols. In the illustrative example shown, a user operating an input-output device 50 wants to communicate with computer 52. The user's device 50 (which may be a so-called “client”) has the SSL or TLS functionality in this particular example. The SSL or TLS functionality is used to create a secure session over which the user's device 50 may communicate with the remote computer 52. Such a secure session is generally protected by encryption so eavesdroppers and other attackers cannot listen in to or alter the data flow.
One of the functions provided by the SSL/TLS protocol is to permit the remote computer 52 to authenticate the user's device 50. This authentication generally works by the remote computer 52 challenging the user's device for a secure credential such as a digital certificate or a key. Generally, you can think of a digital certificate as the cyberspace equivalent of an identity card. Issued by a trusted “certifying authority”, a digital certificate is generally thought of as an electronic credential that can be used to authenticate a user. See for example RFC2510 (“Internet X.509 Public Key Infrastructure Certificate Management Protocols”) (March 1999) and other related IETF publications. However, a digital certificate is generally not considered to be the same thing as a credential. Generally, a certificate may not necessarily alone prove its authenticity. An analogy is a driver's license. A person could hold a stolen driver's license. In contrast, a credential is generally something that can prove its authenticity alone. For example, a signature that nobody can fake or steal may be considered a credential.
One example of a digital credential is a client private key and a client certificate for SSL/TLS client authentication to establish SSL/TLS connection between the client and a proxy server. The combination of the private key and certificate in this example case comprises the credential. The specific credential also covers the security token (see below) since the security token contains a server's signature and certificate. The combination of the server's signature and certificate proves its authenticity.
Digital certificates are now available from a variety of certifying authorities including commercial companies such as Verisign Inc. See for example Verisign's white paper “Establish Trust to Protect and Grow Your Online Business: Authentication and Encryption—The Cornerstones of Online Security”. Some enterprises or networks have set up their own certifying authorities that issue certificates to authorized users within the enterprise or network.
Generally, SSL certificate authentication usually proceeds by having the certifying authority issue a digital certificate to the user's computer. For example, a user who wants a digital certificate can provide credit card, employee number or other identification information to the certifying authority (e.g., but inputting it into a web based form in some cases). The certifying authority typically checks this information to verify the user is who she says she is. Assuming the verification is correct, the certifying authority creates (using public key cryptography) a tamperproof digital certificate for the user. In some cases, the user can download the certificate or the secure credential onto her computer using a standard web browser (e.g., modern versions of Microsoft's Internet Explorer). Such browsers typically provide certificate management tools that allow users to import certificates into a certificate store on the computer's mass storage device. In other cases, a network administrator may physically visit the user's computer 50 to load the certificate onto the user's computer from a floppy diskette or the like.
Once the user's computer has access to an appropriate certificate, it is ready to create a secure (e.g., SSL) connection using certificate-based authentication. In setting up the secure connection, the remote computer 52 challenge's the user's computer 50 to authenticate itself. In response to the challenge, the user's computer 50 sends the secure credential (e.g., a certificate) to the remote computer 52. The remote computer 52 generally uses public key cryptography to validate the digital certificate. Two-way authentication is also possible, i.e., the user's computer 50 can also challenge the remote computer 52 to produce a certificate which the user's computer authenticates. Once the certificate(s) have been validated, the user and remote computers 50, 52 can proceed to establish a secure two-way SSL or other communications session.
The SSL authentication protocol works quite well to provide a reasonable level of security for most commercial, e-commerce, corporate and other transactions. But just as in many secure protocols, secure credential distribution and management is a non-trivial problem. For example, digital certificates are often or usually subject to expiration. Typical digital certificates downloaded from Verisign for example may expire after one year. Furthermore, any digital certificate or other credential which is believed to have been compromised must be immediately canceled so that the authenticating server or other remote computer 52 will not validate it. Canceling or revoking a previously-issued secure credential may also be desired in view of changed circumstances (e.g., when an employee leaves an enterprise or is transferred to a different part of the enterprise, when the composition of a work group changes, etc.). Distributing and maintaining, in a secure way, a valid, appropriate set of digital credentials for a large user community can require substantial time, effort and resources.
Briefly, the illustrative technology herein relates to a first server delivering a credential dynamically to a client after the client has been authenticated and authorized by first server; and the client then using the credential to authenticate itself to a second sever for establishing a secure connection (communication) between the client and second server. In illustrative exemplary implementations described herein, the first server dynamically delivers this client credential to the authenticated/authorized client without caching the credential on client's machine.
The technology herein can be used to deploy secure credentials including but not limited to digital certificates in a secure manner to provide higher levels of security and control than in some other previous arrangements. In one exemplary non-limiting illustrative arrangement, a management server acts as a repository for a plurality of user certificates corresponding to a plurality of users. When a user wishes to access a remote computer such as a secure-enabled host requiring a secure credential, the user controls her computer to send a request message to the management server. The management server may perform its own validity checking (e.g., based on password protection, directory information including user authorization, or a variety of other techniques). Once the management server is satisfied that the requesting user is authorized to access the secure host or other remote computer 52, the management server sends the user the necessary secure credential. This can be over an insecure or secure connection.
Once the management server is satisfied that the requesting user is authorized to access the secure host or other remote computer, the management server sends the user the necessary secure credential in a manner that is on demand (in other words, at the time the client certificate or key pair is needed to complete the connection to another server and not before); is secure during transmission; and is provided in a manner which prevents the client from using the client certificate or key pair to commence a new session to the SSL or SSH hosts after the User's session with server A has ended. In one example arrangement, the user's computer does not persistently store the secure credential but rather maintains the secure credential in volatile memory such as for example random access memory or other memory that will be reliable erased (e.g., by overwriting with other information).
Once the user computer has received the secure credential, it can proceed to attempt to establish a secure connection with the secure-enabled host or other remote computer. Upon receiving a challenge or at some other appropriate time, the user computer may present the secure credential to the host or other remote computer for validation. Once the host or other remote computer validates the secure credential and is thus satisfied that the user computer is authorized for access, the host or other remote computer may proceed to establish a secure connection with the user computer using a conventional security protocol such as SSL, TLS, SSH, etc. In the exemplary, illustrative non-limiting example, the user computer then erases the secure credential after it has been used. Erasure may be accomplished in a variety of ways such as for example overwriting a hard disk sector with random information, commanding a random access memory to erase parts of its contents, etc.
In the example illustrative technology disclosed herein, the secure credential may be any form of secure credential. Examples include an SSL digital certificate in any conventional format (e.g., PKCS #12, PKCS #7, PKI, Microsoft Serialized Certificate Store, or any other standard or non-standardized format). Such digital certificates may, for example, include a digital signature that a certifying authority signs using a private key. Other examples of secure credentials include digital signatures signed by other than a certifying authority, private keys, secure tokens or other authorizations, etc.
By not storing the secure credential persistently on the user computer as in many prior arrangements, the exemplary, non-limiting illustrative technology herein avoids the potential problem of certificate theft. In some prior systems, access to a user's computer is all that is needed for an attacker to make a copy of the user's certificate of other secure credential. Many users leave their computers on all the time without signing off. Any attacker could access the user's computer and make an illicit copy of the secure credentials which the attacker could then transfer to a different computer—thus allowing the attacker to act as an imposter for the real user and engage in secure communications without the consent or participation of the real user.
Another non-limiting advantage of the exemplary technology disclosed herein is minimizing the time, effort and resources needed to maintain and distribute secure credentials. Because secure credentials for a user pool may all be maintained on a management server rather than being distributed throughout a user community with the management server supplying users with secure credentials on demand on a just-in-time basis, a network administrator or other authority can more easily maintain the universe of secure credentials without having to access each individual user computer. This simplifies secure credential distribution and maintenance without substantially increasing complexity.
In some exemplary arrangements herein, the user computer may persistently store the secure credential instead of immediately erasing it after use. Such storage could be on a permanent basis or for a more limited time. In this mode of operation, the management server would be used to simplify the distribution of secure credentials to a user community by providing authorized users with necessary secure credentials on demand. If a previously supplied secure credential expired or was canceled, the user's computer could again contact the management server to request a replacement credential. This persistent storage technique has some disadvantages as compared to the technique in which secure credentials are immediately erased after use, but may also have certain advantages in terms of minimizing traffic to the management server and reducing delay time in establishing secure connections.
In one exemplary illustrative non-limiting arrangement, the user computer may be executing a terminal emulation application and attempting to access a secure-protocol-enabled host computer that requires a certificate before it will establish a secure communications session. The technology herein can supply the user computer terminal emulation application with an appropriate certificate on demand when needed, but may also condition supply of the secure credential on performing its own authorization check (e.g., by confirming in a user or other directory that the requesting user is authorized to access the particular host computer). This technique is compatible with existing technology such as the public key infrastructure and conventional certifying authorities so it does not require, in at least one non-limiting aspect, any widespread change to existing deployed host computers or other such arrangements.